✅ Deploy Preview for rspack canceled.

Built without sensitive environment variables

Hi guys, I have been struggling to investigate the CI "Test Node 18" failure for 2 days. I feel I really need your help.

I believe my implementation can pass all the tests if the tests are run separately.
However, the tests will always be stuck in the config/builtin-swc-loader/swc-plugin case, when they are run concurrently.

My findings so far are that it's stuck in

thanks it maybe related to performance regression, block_on fs binding will cause huge performance regression

I think the biggest blocker now is rspack_resolver doesn't use async_fs, which cause it has to block_on on fs binging call, which will introduce huge performance regression rstackjs/rspack-resolver#34.

but we can still merge this pr first if we don't enable input_fs binding by default and when we solve the rspack_resolver async_fs problem, we can enable inputfs binding

yeah, I also suspect the performance regression, but cannot prove it.

I'm afraid we cannot merge this PR now, because compiler.inputFileSystem has been set by default.

and

if you feel the refactors in this pr are needed, I can create a new pr and cherry pick the refactor commits.

yeah, I also suspect the performance regression, but cannot prove it.

I actually tried it before and revert cause huge performance regression introduced, you can test it in project with large modules like https://github.com/hardfist/performance-compare-ng/tree/master/apps/10000

I'm afraid we cannot merge this PR now, because compiler.inputFileSystem has been set by default.

that's easy, you can just ignore the inputFileSystem in the rust side, it's actually current's behavior

I disabled inputFileSystem on the js side in this PR.

I also created another branch and cherry-picked the refactor commits. maybe #8654 is exactly what you expect.

I disabled inputFileSystem on the js side in this PR.

I also created another branch and cherry-picked the refactor commits. maybe #8654 is exactly what you expect.

yes, good job!

CodSpeed Performance Report

Merging #8643 will not alter performance

_{Comparing nilptr:nilptr/feat/input-file-system (2f93d9e) with main (e32b7ed)}

Summary

✅ 12 untouched benchmarks

@nilptr @stormslowly 你们好，这个 pr 是不是可以支持使用社区的 webpack-virtual-module 的了?

@nilptr @stormslowly 你们好，这个 pr 是不是可以支持使用社区的 webpack-virtual-module 的了?

Yes, i will make a canary version; could you please give it try later?

@nilptr @stormslowly 你们好，这个 pr 是不是可以支持使用社区的 webpack-virtual-module 的了?

Yes, i will make a canary version; could you please give it try later?

ok,thanks. let's talking in Lark.

The canary supports virtual module is
@rspack-canary/core: 1.3.10-canary-20f7fc16-20250514042220
@rspack-canary/core: 1.3.10-canary-4a96390f-20250514074254

add below config in you config file

{
  experiments: {
    useInputFileSystem: true
  }
}

you can reference here https://rspack.dev/guide/start/quick-start#install-canary-version for usage.

感谢 @stormslowly @nilptr 兄的付出 ，1.3.10-canary-4a96390f-20250514074254 版本，已经可以正常运行 webpack-virtual-modules

发现了一个新问题，当使用虚拟模块作为入口文件时，输出的虚拟 js 文件内容为空，并引发了 rspack panic

最小复现 demo 在这里 https://github.com/watsonhaw5566/rspack-virtual-modules-addentry-demo

初步猜想是 compilation.addEntry 当前仅支持真实路径文件，而不支持虚拟文件路径。

@watsonhaw5566 there are a few issues with your implementation.

1. Error: Module not found: Can't resolve 'entry.js' in '/path/to/rspack-virtual-modules-addentry-demo'
   your entry specifier 'entry.js' doesn't start with '/', './' or '../', so the ESM resolution algorithm will search for it in node_modules.
   changing EntryDependency('entry.js') to EntryDependency('./entry.js') or writing the virtual module to node_modules/entry.js can solve this.
2. Error: build failed with unknown error
entryLoader will run for every js file, but it's not allowed to add the same entry multiple times. please reconsider your design, don't abuse loader.

@watsonhaw5566 there are a few issues with your implementation.

1. Error: Module not found: Can't resolve 'entry.js' in '/path/to/rspack-virtual-modules-addentry-demo'
   your entry specifier 'entry.js' doesn't start with '/', './' or '../', so the ESM resolution algorithm will search for it in node_modules.
   changing EntryDependency('entry.js') to EntryDependency('./entry.js') or writing the virtual module to node_modules/entry.js can solve this.
2. Error: build failed with unknown error
entryLoader will run for every js file, but it's not allowed to add the same entry multiple times. please reconsider your design, don't abuse loader.

Thank you suggestions , I'm modify to EntryDependency('./entry.js') , but it will make the Rspack Panic.
But now the question is the compilation.addEntry can't work on loader . #1042

But now the question is the compilation.addEntry can't work on loader .

Don't call compilation.addEntry in the loader.
Loaders are meant for transforming source code, not for interacting with the compilation directly. Modifying the compilation like this is something that should be done in a plugin instead.
If you're trying to inject additional modules or manipulate the build process, I recommend moving that logic into a proper plugin.

It looks like your issues are unrelated to the purpose of this PR. To keep the thread focused, please move this discussion to a new thread in the Discussions section if needed.

📝 Benchmark detail: Open

thanks